Video surveillance systems are conventionally configured as closed-circuit systems wherein one or more video cameras controllably monitor selected areas of interest. The video cameras may transmit video signals over a cable to a control console at which the signals are switched, viewed on monitors, etc. The cable over which the video signals are transmitted may also be used for transmitting information from the control console to the camera, video multiplexer or video switch. For example, commands may be sent from the control console or video switch for controlling pan-tilt-zoom (PTZ) features of a video dome camera, video source selection within a video switch, downloading camera, multiplexer or video switch software updates, etc.
Coaxial cable has been the traditional medium of choice for transmitting analog video signals from the camera to the control console. The process of transmitting control data over the video transmission medium by driving the control data in the opposite direction with respect to the video signals has commonly been referred to as “Up-The-Coax” (UTC) protocol. To prevent the system from acting on commands containing transmission errors, conventional UTC solutions either repeat transmitted commands multiple times to provide redundant transmissions, or use bi-directional communication whereby an acknowledge handshake signal is provided by the camera in response to a received command.
Filtering out corrupted commands typically requires the device receiving the command to verify the checksum, parity, or CRC of the transmitted signal. Redundant transmission methods can require consecutive, identical commands before acting on them. However, verification using these techniques can be impossible when multiple messages are corrupted. Current bi-directional schemes address this issue by transmitting a command, e.g. to the camera, during one vertical interval of the video signal and transmitting an acknowledge (ACK) reply message back to the controller during the next vertical interval. If the reply message indicates a negative acknowledge (NAK), the controller would re-transmit the command on the next vertical interval. This sequence causes a latency of two vertical time periods.
Both redundant and bi-directional UTC protocols have typically been limited to transmitting/receiving four bytes of data per vertical period of the video signal. This command size restriction has made it impractical to pack variable speed command data for all axes of a video dome camera into a single transmission. With the limited byte count, simultaneous panning and tilting in a video dome camera has required multiple commands.
Some UTC protocols have transmitted 16-bit words in each of two horizontal line periods of the video signal. These schemes use shorter pulse widths to allow the command word to fit between two horizontal pulses. When UTC commands are transmitted over long distances, the pulses have slower rise and fall times and are delayed with respect to the video generated at the receiving end. The slower rise and fall times place a practical limit on how narrow the pulse widths may be to facilitate detection by low cost detection circuits.
The pulse widths conventionally used when transmitting 16-bit words in a horizontal line require the words to occupy most of a horizontal period. To prevent the last pulse of a UTC command from interfering with the next horizontal sync pulse from the camera, the length of the transmission cable must be limited. For example, with RG59 coaxial cable, the length must be less than 2500 feet. Wider pulses are not as easily degraded beyond usable limits due to rise and fall times, however wider pulses reduce the usable cable length because they reduce the margin between the end of a command word and the following horizontal sync pulse.
The useful length can be stretched by starting the transmission before the color burst signal. Corrupting the color-burst signal during vertical blanking may have a noticeable effect on the image depending on the system configuration. Overlapping the command with the color-burst can require a more sophisticated detection circuit at the camera end to distinguish weak command pulses. Reply data transmitted by the camera device is subject to the same cable related delays as the video signal.
Also, known systems have required complex repeater configurations for re-driving the video signal with embedded reply data from the video dome, while capturing, buffering and re-inserting the UTC data from the controller in the next vertical interval. It is desirable to allow longer runs of transmission media without requiring expensive repeaters, simply to avoid UTC command interference. For systems with very long transmission media and reasonable signal loss, e.g. fiber-optic cable, it is desirable for the device that is supplying the video signal to have a receiver capable of accurately separating command pulses that overlap horizontal sync pulses or color burst that is being transmitted in the opposite direction. Some UTC protocols only transmit one byte of data per horizontal line. This smaller data packet allows longer transmission delays without interference with the horizontal sync. Single byte packets can also be encoded with wider pulse widths making them more tolerant of attenuation and the longer rise-fall times associated with long or lower-cost, lower-quality cable runs. However, with the limited number of horizontal lines available for bi-directional communication during a single vertical blanking period, the single byte approach limits the total command size to half that available with 16-bit per horizontal schemes.
Another difficulty associated with conventional UTC protocols is that they render downloading large firmware updates through a series of 4-byte UTC commands impractical. In order to add new functions to current dome control systems, an operator uses pre-numbered function keys or multiple key combinations to send commands to control the new functions. Most controllers do not provide enough spare function keys for future functions. Using multiple key combinations is cumbersome due to the difficulty in memorizing the combinations. Moreover, the common and most frequently used commands typically include dedicated and clearly marked keys. New special functions tend to be used infrequently, and, as such, would benefit the most from labels or help screens.
The functions that need to be performed by the function keys or key sequences are not known at the time of manufacture of the controller and are, therefore, not labeled on the controller. Some controllers have screens that can be used to display labels or help for the function keys, but the functions must still be known at the time of manufacture, or updates for the controllers must be installed as new features are added. When new video domes are developed with new features that require new commands, the controllers in the field must be upgraded or the operators will be forced to memorize keys or key sequences to use the new features.
Conventional UTC techniques are therefore inefficient in the transmission of control commands and data over a transmission medium to a video dome, switch, recorder, etc. In fact, simple movement control of video dome-type devices has noticeable latency. Also transmission of new software updates is slow enough to be deemed impractical, and adding control functions to an existing system is difficult.
Accordingly, there is a need for improving the speed of downloading control commands and data over a transmission medium to a video dome, switch, recorder, or other video surveillance system device. There is also a need for a facile and efficient method implementing new functions in a video system controller.